Fix confirmed findings from the #389 adversarial review - #414

The multi-agent review of PR #389 (incident forensics hardening)
confirmed 15 findings, 6 with real behavioral impact. All are
addressed here, plus the load-bearing comment rot it flagged.

feedDebugLog.ts (5 behavioral fixes):

* Pre-existing over-cap files never got a tombstone. Priming
  tombstoneWritten from `startingBytes >= cap` routed the first
  post-upgrade batch into the already-capped short-circuit, which
  never writes a marker — so the 60-300 MiB pre-cap-era files that
  MOTIVATED the cap (#388) had appends dropped silently. Now primes
  false; the first batch flows through the cap branch, writes the
  tombstone, then latches.

* Tombstone write failure silently latched as "capped". The bare
  catch around the tombstone append still set tombstoneWritten=true,
  so an ENOSPC (the exact pressure the cap exists for) produced a
  file with no marker that the code believed was cleanly marked.
  Now latches only on success; on failure the next batch retries the
  tombstone (one small append attempt per batch).

* stat() failures failed OPEN at 0 bytes. Any non-ENOENT error
  (EACCES, EIO, EMFILE — fd exhaustion is likeliest under exactly
  the load the cap targets) primed the counter at 0 and let an
  already-300 MiB file grow by another full cap. loadInitialFileBytes
  now returns null for unknown-size; the caller fails CLOSED —
  unprimes and returns without advancing the cursor so the renderer
  resends and the next batch re-stats.

* forgetFeedDebugSession racing the stat() await leaked map entries.
  get → await → set meant a forget during the await deleted a
  not-yet-existing key, then the continuation inserted state for a
  dead session — permanent leak since session UUIDs never recur.
  The placeholder now lands in the map BEFORE the await; an identity
  re-check after it detects the forget and bails.

* On-disk droppedEntriesSoFar froze at the first batch's count.
  Capped sessions kept flooding for hours while the tombstone
  reported the first few hundred drops. A refreshed tombstone row is
  now appended each time total drops DOUBLE since the last row —
  log-bounded (~20 rows for a million drops) and the last row is
  always within 2x of the truth.

* Batch drops were all-or-nothing. A 40 MiB batch whose LAST bytes
  crossed the cap discarded all 40 MiB even though most entries fit.
  Entries are now serialized per-line and the cap cuts WITHIN the
  batch: the admitted prefix is written in the same append as the
  tombstone (JSONL prefixes are always valid; no torn interleaving).

previousRunClassifier.ts:

* main_oom_suspected dropped minidumpPath — a regression. V8 fatal
  aborts raise SIGABRT, so Crashpad writes a minidump for the same
  crash the diagnostic report describes. The new OOM branch returned
  before the minidump lookup, so evidence lost `native`/`minidumpPath`
  for exactly the crash class the branch was added to improve, and
  downstream symbolication read undefined. The OOM branch now runs
  findRecentMinidump too.

* Fixed both "trigger is a top-level string" comments: trigger lives
  under `header` in Node diagnostic reports. The regex works because
  it is a flat text scan; the comments now say so explicitly and warn
  against "simplifying" to JSON.parse(prefix).trigger, which returns
  undefined and would silently kill every OOM classification.

heapWatchdog.ts:

* The threshold comment claimed the ~1.2 GB abort class "was already
  covered by the ratio" — algebraically false on the 2026-05-11 host
  (ratio arm resolves to ~3.0 GiB; both old and new trips sit above
  1.2 GB). Replaced with an honest coverage note: low-peak aborts are
  attributed post-hoc by reportOnFatalError + the prior-run
  classifier; polling only buys a pre-crash snapshot for climbs
  crossing ~1.5 GiB, and why the trip is not lowered further.

index.ts:

* setDebugRetentionJournal(appRunJournal) moved BEFORE
  appRunJournal.start(). start() fires the run's first prune
  (incident-run-start), and with the sink wired after the await the
  first prune's journal entry was race-free only because the prune's
  statfs() I/O happened to lose to the synchronous continuation —
  any future await inserted between them would silently drop the
  breadcrumb. Wiring first makes the ordering structural. The old
  comment (which misdescribed 'startup' as the first prune) is gone.

Verification: applied to a clean main checkout — `tsc -b
tsconfig.node.json` exit 0, `tsc --noEmit -p tsconfig.web.json`
0 errors. No new tests per repo convention.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>